1. Technical Field
The present invention is generally directed to object-oriented programming languages, and more specifically to the field of object-oriented software development.
2. Description of Related Art
In computer software development, it is important to be able to save and restore the state of the developed applications as those applications are programmed, tested and debugged. Developers of Java® create computer software component technology called JavaBeans® using the specification set forth by Sun Microsystems, Inc., Palo Alto, Calif. The JavaBeans specification describes a technique called “serialization” to save and restore component state of a JavaBean during development. According to the JavaBeans specification, the act of serialization is delegated to the JavaBean itself.
Java development environments that comply with the JavaBeans standard, for example AppDev Studio from SAS Institute Inc., Cary, N.C., require a robust technique for saving the state of the developed applications. Because these development environments are tools for wiring together JavaBeans components, serializing a given application's project state involves serialization requests to the JavaBeans themselves.
A problem with the current JavaBeans serialization model is that it does not provide appropriate hooks for error recovery and is stored in a binary format which is not effectively understandable by a component designer. If a particular JavaBean cannot be instantiated to restore the state of a saved project, the project cannot be opened. If the serialization file is corrupted in any manner or the serialization format changes because of an update to a particular JavaBean, no matter how minor, serialization halts without any chance of recovery. Such limitations are clearly not acceptable in a project development environment. JavaBeans under development will change quite regularly and an application development tools must be expressly designed to handle such occurrences.
Sun Microsystems has recognized this problem and have attempted to overcome this problem in several ways through its more recent software releases. However, Sun Microsystems' approach only allows for the serialization of the public state of an object (that state which can be queried or set via public method calls or public fields). This is insufficient as many objects contain internal states that must be captured in order to properly restore them at runtime.
Moreover, the implementation of Sun Microsystems does not allow objects to specify the order in which their state is restored. This can lead to errors at runtime where several values have interdependencies. Consider an object in a frame with a particular property whose value is bounded by two of the object's other properties. Such an object may be used in a frame that has been developed with a web development software package, (e.g., WebAF from SAS Institute Inc., Cary, N.C.). The frame may include in its graphical user interface (GUI) a spin control that a user increments or decrements to a desired value. The spin control is an object with a particular property whose value is bounded by two of the object's other properties. The “count” property of the spin control is bounded by its associated “minCount” and “maxCount” properties. If the boundary parameters are not set before the bound value, an invalid state could result during object restoration, resulting in a runtime error.
IBM, from Armonk, N.Y., has developed a technology called Bean Markup Language (BML) that uses an XML (extensible Markup Language) format to save application state. This XML state is then used by a runtime interpreter to instantiate the application and “play it back”. An analogy would be a streaming audio format that can only be played back with a proprietary “player”. The IBM approach has the same shortcomings as the approach of Sun Microsystems. It also requires that a runtime player be installed on all client machines that intend to play back the application. The BML player uses a Java technology called “reflection” during runtime playback of the BML file. This results in significant performance degradation. Finally, BML is not Java code, and many end users expect to see and use the Java code produced by the development environment.
Other Java development environment producers use straight code generation to save Java component state (i.e., they do not use JavaBeans serialization in any form). This somewhat limits the set of components that they can interact with and the interactions that can be performed such that the state can be correctly saved. For example, any component that relies on non-public methods or fields to capture state cannot be manipulated by such a tool. Additionally, JavaBeans customizers, which provide a user-friendly way for customizing the state of a JavaBeans component, rely on JavaBeans serialization and thus cannot be used in such an environment.